I tried this patch with MHD and many of the headers are being overwritten with default values. I used the command

--source-seq-file="C:\Users\natha\Documents\SonoEQ\AA_3D Scan_2019_09_12-15_53_25\UnfusedVolume.mhd"
--output-seq-file="C:\Users\natha\Documents\SonoEQ\AA_3D Scan_2019_09_12-15_53_25\UnfusedVolume.mhd"
--operation=UPDATE_FIELD_VALUE
--field-name=sonoEQ.Hardware.version
--updated-field-value=myValue
--maintain-custom-headers
"sonoEQ.Hardware.version"

On the right is the mhd before the command, on the left is after.

Also, if you use this command with .mha's, the same thing happens to the headers and the image data is deleted.

@dzenanz could you confirm this?

I will look into this.

With a file I have lying around I could observe ElementSpacing changing from 0.1 -0.0385753 0.1 to 1 1 1. While I debug that, @nathanbmnt can you share AA_3D Scan_2019_09_12-15_53_25\UnfusedVolume.mhd (just the header)?

ElementSpacing changes from 0.1 -0.0385753 0.1 to 1 1 1 even before this patch. I guess that vtkIGSIOTrackedFrameList does not record, and therefore does not preserve ElementSpacing. That tag is only handled per-frame. I could add a commit which tries to preserve that if frame ElementSpacing is set.

Force-push just rebases the commit on top of current master.

I pushed a new commit for ElementSpacing change in IGSIO/IGSIO#23.

@dzenanz here is the file

https://drive.google.com/file/d/1Nizde_rPzhwxdMr7ncUN5aiEdxolTAZi/view?usp=sharing

Notice that in the above screenshot CompressedData and dimSize are also changed

There are some changes for me (using updated branches after rebase), but dimSize is unchanged:

Whether to write the output file compressed is controlled by --use-compression command line parameter to EditSequenceFile. If it is provided, the header has:
CompressedData = True and CompressedDataSize = 0 (many extra spaces for the size to be calculated). I agree that this case is broken, but I could not figure out whether the input file was compressed from read function:

The force-push changes the logic so in-place change of the header is not attempted if compression is requested.

The volume in the example with an element spacing that wasn't ElementSpacing = 1 1 1 was a volume output from VolumeReconstructor.exe which is a static volume and not a Sequence volume. Therefore it was probably correct behavior for EditSequenceFile.exe to save it as though it was saving a sequence as PLUS usually does when writing volumes with VirtualCapture. Otherwise trying to maintain element spacing field from the input would probably make this tool more of a general Volume Header edit tool whether it is a sequence or a static volume.